Repository navigation
Conversation
…ationEngine#520) setConfigurationProperties saved the map before building the in-memory copy, so an invalid PUT body was written to the database and then threw, corrupting the configuration map on restart. Validate the map first, build the in-memory maps, and persist last. Signed-off-by: iacsha <122627209+iacsha@users.noreply.github.com>
19185b5 to
1747960
Compare
|
Thanks @mgaffigan. DCO sign-off is fixed on all my open PRs. On the get/put point: I think they already share one implementation.
So a map read back from the database is checked by the same code that checks a PUT, and they can't drift apart. One gap I did notice on the read side: if a bad map was already stored before this fix, the load path catches the |
|
This is a duplicate of #552 . I don't mind if you want to take over the fix, but please compare this to the existing PR to see if any part of it should be included in yours. It's still in a draft because it is stacked on top of #515 and was waiting for that one to merge to rebase. I don't remember exactly what's in it now, but I think it adds some tests that depend on 515 merging first. Additionally, new contributors are being asked to sign the Eclipse Contributor Agreement. It is now described in section 8 of CONTRIBUTING.md. The failing check on all of your PRs should go away once you have completed that step. |
Validate the configuration map before persisting it (fixes #520)
Problem
PUT /api/server/configurationMapdoes not check the map it receives. The XML/JSONbody readers deserialize into a raw map, so the body can produce a null map, a null
key, a non-string key, or a null / non-
ConfigurationPropertyvalue.DefaultConfigurationController.setConfigurationPropertiespersists the map beforeit builds the in-memory copy:
So a bad map is written to the
CONFIGURATIONtable first, and the in-memory updatethen throws. With
configurationmap.location = databasethis leaves a row that breaksthe configuration map on the next startup — the request 500s but the damage is already
persisted.
Fix
validateConfigurationMap(map): rejects a null map, and any entry with anon-string key or a null / non-
ConfigurationPropertyvalue, throwingControllerExceptionbefore anything else.setConfigurationPropertiesto validate → build the in-memory maps →persist last, so an invalid map can never reach the database.
The database-load path (
loadDatabaseConfigPropsIfNecessary) already catchesControllerExceptionand logs it, so a server already bricked by this bug now startsand skips the bad map instead of failing to load.
Tests
Added to
DefaultConfigurationControllerTest:ControllerException./gradlew :server:test --tests "*DefaultConfigurationControllerTest*"→ 19 tests, 0failures.
Not included
The deeper fix — making the XML/JSON body readers honor the map's generic types so a
raw map can't be constructed in the first place — is left for a follow-up to keep this
change focused on preventing the persistence corruption.